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(57) ABSTRACT 

A method for facilitating communication between collabo- 
rators in a HyperText Markup Language (HTML) environ- 
ment which includes the steps of: receiving data via a 
network connection; storing the received data in a database; 
retrieving an HTML file from a memory element; and using 
the stored data in conjunction with the HTML file to 
generate an HTML page for display. The data received via 
the network connection includes an indication that an HTML 
page includes discussions among collaborators. The HTML 
page rendered for display includes at least one discussion 
among collaborators. A corresponding system is also dis- 
closed. At least one vote/poll item can be embedded within 
a discussion group. 

21 Claims, 13 Drawing Sheets 
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METHOD AND APPARATUS FOR 
FACILITATING COMMUNICATION 
BETWEEN COLLABORATORS IN A 
NETWORKED ENVIRONMENT 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application continuation-in-part of U.S. patent appli- 
cation Ser. No. 08/893,111, filed Jul. 15, 1997. 

FIELD OF THE INVENTION 

The present invention relates to networked systems and, 
more particularly, to electronic distribution of products. 

BACKGROUND OF THE INVENTION 

The world wide network of computers commonly known 
as the "Internet" has grown rapidly over the last several 
years. Much of this growth has been driven by the increase 
in popularity of the World Wide Web ("WWW" or "Web"). 
The WWW is a collection of files written using HyperText 
Markup Language (HTML), commonly referred to as "Web 
pages." HTML files may be easily configured and created by 
users and accessed and displayed using specialized applica- 
tions known as Web browsers, which allow a user to access 
and view HTML files using a graphical user interface. 

Partially as a result of this growth in popularity, many 
products can now be distributed to consumers with relative 
ease. Unfortunately, many users will not purchase a product 
without first trying the product. However, it is currently 
difficult to subsequently control access to a distributed 
product. 

SUMMARY OF THE INVENTION 

The present invention relates to systems and methods for 
controlling access to a product that has been distributed. In 
particular, the systems and methods described below allow 
a product to be distributed to a user for demonstration 
purposes without losing control of usage of the product. The 
systems and methods described below also allow multiple 
users access to a product for demonstration purposes while 
requiring only a single authorization to grant access to all 
users. 

In one aspect, the present invention relates to a method for 
controlling access to a product. A request is received for a 
product. A license string that controls access to the product 
is generated substantially at the time the request is received. 
The generated license string is transmitted to the requester. 
The requester may enter the license string into the product 
in order to gain access to it. 

In another aspect, the present invention relates to a system 
for controlling access to a product. The system includes an 
input unit which receives a request for a product. The syslem 
also includes a license string generator in electrical com- 
munication with the input unit. The license string generator 
produces a license string that controls access to the product. 
The license siring is generated substantially at the time a 
request is received. The system also includes an output unit 
for transmitting the generated license string to the requestor. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is pointed out with particularity in the 
appended claims. The advantages of the invention described 
above, as well as further advantages of the invention, may be 
better understood by reference to the following description 
taken in conjunction with the accompanying drawings, in 
which: 
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FIG. 1 is a block diagram of a system for providing a 
collaborative work environment; 

FIG. 2 is a diagrammatic view of a facility as stored by a 
server database; 
s FIG. 3 is a diagrammatic view of a client workstation that 
may be used in the system of FIG. 1; 

FIG. 4 is a screen shot of an HTML page viewed by a user 
of the system of FIG. 1; 
10 FIG. 5 is a flowchart of the steps taken by a client 
workstation to render an HTML page of the sort depicted in 
FIG. 4; 

FIG. 6 is a flowchart of the steps taken by a client 
workstation to allow users of the system to edit files; 
is FIG. 7 is a flowchart of the steps taken by the client 
workstation to allow users of the system to upload files to a 
server using a "drag-and-drop" interface; 

FIG. 8 is a flowchart of the steps taken by the system to 
transfer a file using HTTP; 
20 FIG. 9 is a screen shot of one embodiment of an eRoom 
containing a discussion group item in the item box; 

FIG. 10 is a screen shot of one embodiment of an eRoom 
displaying a discussion group item; 

FIG. 11 is a screen shot of one embodiment of an eRoom 
displaying a discussion group item associated with an item; 

FIG. 12 is a screen shot of one embodiment of a dialog 
box presented to a user to create a vote/poll item; and 

FIG. 13 is a flowchart of the steps taken to electronically 
30 distribute and control access to a file. 

DETAILED DESCRIPTION OF THE 
INVENTION 

Referring now to FIG. 1, and in brief overview, a system 

35 for providing a collaborative work environment via a net- 
work is shown. Client workstations 12' are connected to one 
or more servers 14. The client workstations 12' may be 
connected in any physical arrangement such as a star, loop, 
ring, or bus. The network connecting client workstations 12' 

40 and the server 14 may use any physical media, including 
wireless, provided that the physical media supports the 
HyperText Transfer Protocol (HTTP). 

The server 14 stores information relating to a project or a 
set of projects, referred to as a facility, in a database 20 

45 which may be a flat database, relational database, multi- 
dimensional database, or object-oriented database. Each 
server 14 may store more than one database 20, where each 
database 20 represents a different facility. For example, one 
server may host project facilities for separate research efforts 

50 within one organization or for separate research efforts by 
separate organizations. Each facility is viewed by a user as 
a directory of eRoom pages. Referring now to FIG. 2, a 
directory of eRooms 22 as stored in the server database 20 
is shown. Each entry provides at least one link to an eRoom 

55 front page 24, which in turn may contain other eRoom pages 
27, folders containing database objects 28 or files 29. 

Databases 20 may be stored by the server 14 on any 
convenient mass storage device. For example, FIG. 1 depicts 
an embodiment in which the server 14 stores the database 20 

60 on an associated hard disk drive 16. Alternatively, the server 
14 may store the database in Random Access Memory 
(RAM) if the database 20 is capable of fitting within the 
physical memory space of the server 14. The server 14 
responds to requests for portions of the database 20 made by 

65 the client workstations 12' and transfers the requested data 
objects over the network to the requesting client workstation 
12'. 
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The server database 20 stores various tables which con- 
tain information about eRooms, members, access controls, 
and other data objects. For example, a members table may 
be provided which includes unique identification codes for 
each user, a table value indicating for which eRooms the 
user fulfills a coordinator role, a table value which indicates 
for which eRooms the member fulfills an observer role, and 
a value describing the last time the member record was 
modified. Similarly, an eRooms table may be provided 
which includes a globally unique handle identifying the 
eRoom and one or more room flags which indicate various 
room attributes, such as whether a coordinator can create an 
eRoom, or whether the eRoom is a temporary, or trial, 
eRoom. Objects may also be represented by a table which 
includes as fields identification codes for each data object, 
one or more flags which are used to distinguish various 
objects, one or more flags which are used to determine the 
behavior of objects (editability, searchability, and others), a 
field indicating the date the object was created, a field 
indicating who created the object, a field identifying the 
parent of the object, and a field identifying the date the 
object was last modified, among others. 

Referring also to FIG. 3, The client workstation 12* may 
be any machine that supports reception and transmission of 
data signals over an HTTP network. In general, a client 
workstation 12' is a personal computer executing a 
"browser" program to display an HTML page 40, on the 
screen 30 of the client workstation 12'. The user interacts 
with pages displayed by the browser utilizing a "point-and- 
click" interface, i.e., the viewing user uses a mouse 32 to 
manipulate a cursor 42 that is also displayed on the screen 
30 of the client workstation 12'. Once the cursor 42 is over 
a particular portion of the HTML page 40, the viewing user 
signals by "clicking" or "double clicking" a button 33 on the 
mouse 32. Alternatively, the viewing user may also signal by 
pressing a key on an associated keyboard 36, such as the 
"return" key. In other embodiments, the viewing user may 
not use a mouse 32 at all, but may instead use a touchpad, 
a trackball, a pressure-sensitive tablet and pen, or any other 
input mechanism for manipulating the cursor. 

The client workstation IT uses a local database 20' to 
store data objects related to a project, while external files 
related to a project (such as a word processing document of 
a set of meeting minutes) are stored in the client worksta- 
tion's 12' local file system. The client database 20' may be 
provided as a flat file database, relational database, multi- 
dimensional database, or object-oriented database. For 
example, a typical relational database that may be used to 
provide a client database 20' is Jet Database Engine, manu- 
factured by Microsoft Corporation of Redmond, Wash. The 
database 20' stored on the client workstation 12' contains a 
relevant subset of the data objects stored by the server 14. 
That is, the database 20' stored by the server 14 typically will 
contain more information about a particular project than the 
database 20' stored by the client workstation 12*. 

However, the database 20' stored on the client workstation 
12' may contain tables which are not stored by the server 
database 20. For example, a client workstation 12 may store 
in its database an "unread" table which indicates which 
objects have been modified since the user of the client 
workstation 12' has last accessed those objects. An unread 
table may include a member identification field and a 
modification tag indicating the last modification date and 
time of an object. All records may be read from this table to 
identify to the client workstation 12' every item in a par- 
ticular eRoom page which has not been read by the user, or 
a selective database query may be done to return only those 
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objects belonging to a particular set of eRoom pages that 
have not been read by the user. If it is desired to provide this 
functionality, an additional entry in the unread table must be 
made to allow data objects to be distinguished based on 

s some indication of affiliation. 

Certain important information, such as hierarchy and 
navigation information, related to the project database 20 is 
considered "skeleton" information. Skeleton information is 
a set of database records that contain basic properties needed 

10 to display Web pages representing the project and therefore 
client workstations 12' require frequent updates of this 
information. Accordingly, it is generally desirable to exclude 
large information from skeleton information associated with 
a project, such as notes relating to an ongoing discussion, to 

1 5 facilitate transmission of the skeleton information to client 
workstations 12'. 

The client workstation 12' uses project data received from 
the server 14 in combination with one or more template files 
to create and display to the user of the client workstation a 

20 private, secure collection of HTML pages that provide a 
virtual workroom for members of a team, whatever its size 
and wherever the members of the team are physically or 
corporately located, may be referred to throughout as an 
"eRoom", or an "eRoom page". An eRoom is a set of 

25 connected HTML pages displayed to a user that displays 
project-related files, data, and discussion lists. Members of 
a team may congregate, share work and files, discuss ideas, 
stay informed and otherwise collaborate on common 
projects using an eRoom. 

30 Client workstations 12' generally have local memory 
elements for storing data objects of files associated with a 
project that are downloaded from the server 14 as well as 
one or more eRoom templates. A client workstation 12' may 

35 have an associated mass storage device such as a hard disk 
drive 16 ( or a tape drive 18' for storing the set of eRoom 
templates, although if a client workstation 12' is provided 
with enough RAM to store the set of eRoom templates, then 
the mass storage devices need not be provided. 

40 FIG. 4 depicts an embodiment of an eRoom page 60 that 
a user might encounter while using a popular "browser" 
program, Internet Explorer, manufactured by Microsoft Cor- 
poration of Redmond, Wash. The eRoom page has five 
major elements: a page element 402; a navigation bar 404; 

45 a graphical identifier 406; an item box 408; and a shortcut 
list 410. 

The page element 402 may include subelements. In the 
embodiment depicted in FIG. 4, a discussion 420 is embed- 
ded within the page and there is a facility to allow a viewer 

50 to contribute to the discussion 422. The embedded discus- 
sion 420 and the contribution facility 422 may be imple- 
mented as ActiveX controls, a JAVA applet, or various other 
means. Further, the facility name is displayed 424, as is the 
name of the viewed page 426 and a description of the viewed 

55 page 428. 

The navigation bar 404 provides a number of controls for 
the viewer of the page. For example, in the page embodi- 
ment shown in FIG. 4, the navigation bar 404 provides eight 
commands; "find," 442 which performs a find for a specified 

60 object; "members," 444 which permits certain users to 
change the membership list and access levels associated 
with members; "create," 446 which allows certain users to 
create new items and pages; "edit," 448 which allows certain 
users to edit eRoom pages; "settings," 450 which permits 

65 settings for the display and management of eRooms to be 
changed; a question mark icon 452 which invokes a help 
system; a "next unread" icon 454 which displays to the 
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viewer an unread item or file; and an up-arrow icon 456 
which displays the "parent" of the eRoora currently being 
viewed, that is, it displays an eRoom page one logical level 
"up" from the currently viewed eRoom page. 

The graphical element 406 is used to pictorially identify s 
the viewed page. The graphical element 406 may be a 
corporate logo or other organizational identifier. The graphi- 
cal element 406 may be static (as depicted in FIG. 4) or it 
may be a dynamic identifier such as a JAVA script or 
ActiveX control. 30 

The item box 408 collects and displays items associated 
with the project represented by the page 402. In the embodi- 
ment shown in FIG. 4, the item box 408 contains a folder of 
items 482, a notes file 486, a spreadsheet file 488, and a word 
processing file 490, each of these being links to other eRoom ^ 
pages or files. Other items which may be displayed in an 
item box 408 are version organizers, discussions, links, and 
vote/poll items which survey team membership on one or 
more issues. As will be discussed below in greater detail, a 
discussion item may be associated with any other item in an 20 
eRoom and a discussion item can be contained in an eRoom 
as a stand-alone item. In further embodiments, discussion 
items may be embedded within other items contained in the 
eRoom. Each discussion item may itself include at least one 
vote/poll item that allows discussion participants to decide 2 5 
issues related to the discussion. In some embodiments, the 
vote/poll item is presented to the user "in line" with a series 
of discussion group entries (see FIG. 10). A vote/poll item 
may also be included in an eRoom as a stand-alone item. The 
item box may also include a facility for creating new items 30 
492. The item box 408 may also include icons which control 
how items are displayed in the item box 408. In the 
embodiment shown in FIG. 4, three icons are provided: an 
"icon display" icon 494 (currently selected) which causes 
items to be displayed as large icons with identifying text 35 
underneath; a "hst display" icon 496 which causes items to 
be displayed as small icons with identifying text to one side 
of the icon; and a "report display" icon which causes items 
to be displayed as a list. The displayed list may be 
alphabetized, ordered by size of item, ordered by creation 40 
date, ordered by modification data, or ordered by some other 
data field associated with each item. 

Items in the item box may include a graphical indication 
that it, or items contained within it, are unread. This may 
imply that the item has been newly created, or the item may 45 
have been modified since the viewing user last read it. In 
either event, the graphical indication signals the user that the 
item should be read. In FIG. 4, the "Brainstorms" folder 482 
has an indication 484 that it is unread. 

eRoom pages also may include a shortcut bar 410. The 50 
shortcut bar is a list of shortcuts which provide the viewer 
with a convenient way to access other eRoom pages. For 
example, in the embodiment shown in FIG. 4, a shortcut to 
the directory of eRooms is provided, as well as shortcuts to 
the page currently viewed 414 and a shortcut 416 the folder 55 
482 displayed in the item box 408. The folder shortcut 416 
includes a graphical indication that there are unread items in 
the folder 417. The shortcut to the front page of the eRoom 
currently being viewed 414 also includes a graphical indi- 
cation that unread items exists in the page 415. Shortcuts 60 
may be added to the shortcut bar by the viewing user. In 
order to read the unread items in the folder 482, the viewing 
user may use the shortcut 416 to access the contents of the 
"Brainstorms" folder 482 and determine which items are 
unread or the user may simply click on the "next unread" 65 
icon 454. The shortcut bar 410 may be provided as an 
ActiveX control or as a JAVA applet or other means. 
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As noted above, users interact with eRooms by using Web 
browsers in a traditional manner. That is, users may traverse 
a hyperlink to access an eRoom, or users may directly enter 
a URL address into the browser. Regardless of the manner 
in which the URL address is accessed, the browser retrieves 
the HTML file in order to display it. However, if the URL 
address is an eRoom, the server of the file returns a file of 
control information, referred to as a "wrapper" file. The 
wrapper file is an HTML file which contains, among other 
information, an identification of the object to be displayed. 
The wrapper file delivers an object ID which is used by the 
client workstation 12' to look up the object in the local 
database 20 stored on the client workstation 12'. The local 
database 20 includes information about the object, including 
which eRoom template to use and information regarding any 
"children" the object may have (for example, items con- 
tained in the item box). 

Generation, display, and management of eRooms is con- 
trolled by a "page builder" application residing on the client 
workstation 12'. The page builder application may be pro- 
vided as specialized hardware or software operating on a 
general-purpose machine. In some embodiments, the page 
builder application may be provided as an Active X control 
or a COM object. 

Referring to FIG. 5, the first step that is taken by the page 
builder application is to retrieve the eRoom template indi- 
cated by the wrapper file (step 502). An eRoom template is 
an HTML file having additional eRoom-specific information 
embedded in it. The eRoom specific information is generally 
distinguished from HTML tags. For example, eRoom- 
specific information in an eRoom template may be sur- 
rounded by and "»". Any symbol or set of symbols 
may be used to distinguish eRoom-specific information so 
long as eRoom-specific information is distinguishable from 
HTML tags. 

eRoom information in a template includes sections con- 
trolling the page itself, the controls on it, and the way the 
page's data is presented the page is created or edited. 
The Template section controls several miscellaneous 
items about the template itself, for example, the Tem- 
plate Section may include name information, informa- 
tion specifying which thumbnail appears when the page 
template is selected, a description of the identifying 
text that appears under the thumbnail, how children 
(i.e. dependent pages) of this type of page are counted, 
and whether the page should open automatically when 
created. In one embodiment, the Template section of a 
Folder may be configured in the following manner: 



Begin_Template 

{ 

category - container 
wizardname - "Folder" 
thumbnail - folder 
Icon - 0 
DYNAMIC 
{ 

Suffix - "item" 
SufiSxPl = "items" 
OpenOnCreate - "no" 

Blurb - "A container for storing and organizing flics, links and 
other pages." 

} 

} . 



The template section above specifies the folder template's 
name ("Folder"), thumbnail, default icon, and identifying 
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text (blurb). "OpenOnCreate" specifies that folders are not 
automatically opened when created, and "Suffix" and "Suf- 
fixPl" control the text that appears with the child count in 
the size column when a folder appears in an item box. 
DYNAMIC sections allow the template creator to add s 
properties to a page that are not standard template properties. 
For example, in the example above, Suffix, SuffixPl, 
OpenOnCreate, and Blurb have been added to this template 
by the template creator. The following is an exemplary list 
of various template properties that may be used in embodi- 10 
ments of their invention: 
Template Properties 

Category: specifies which set of icons is presented when 
a "Change Icon" command is attempted on items with this 
template. Valid choices are "container" (for folders and 15 
version organizers), "content" (for note pages) and "discus- 
sion" (for discussions). Discussion notes do have a category 
("note"), but actually they never appear with icons. 

Wizardname: specifies the name of the template when it 
appears as a choice in the page wizard. "Folder" and "Note" 20 
are examples of these. 

Thumbnail: which thumbnail to display when this tem- 
plate is selected in the page creation facility. Thumbnails 
may be .bmp files stored in a predefined subdirectory which 
refers to them by name without the .bmp extension. 25 

Icon: the index number (within the icon set specified by 
"Category") of the default icon for items with this template. 

Suffix: the string to use after the child count in the size 
column when items with this template appear in the item 
box, e.g., "item" for folders, "note" for discussion, "version" 30 
for version organizers. This property must be placed within 
the braces of a "DYNAMIC{}" subsection within the Tem- 
plate Section. 

SuffixPl: the plural version of the Suffix, e.g., "items", 
"notes", "versions". 35 

OpenOnCreate: whether or not to open new items of this 
type automatically when created. "No" for folders, generally 
"Yes" for everything else. 

Blurb: the identifying text that appears under the thumb- 
nail when this template is selected in the page wizard. 40 
The Control section(s) appear for each eRoom discussion 
or item box on the page, setting various properties like 
the column headers of an item box, or the sort -direction 
of a discussion. In one embodiment, the Control section 
for the item box in a Folder may be configured in the 45 
following manner: 



Begin_Control 

{ 

control name - ERPagc 
wizardname - "contents" 

childlypo - "container, discuss ion,content,external,liiik" 

dcfaulttargct - yes 

DYNAMIC 



{ 



Initial View - "Report" 
ShowCrcation - FALSE 
ShowModifyTme - True 
ModifyWidth - 116 
SizeWidth - 68 
Width - 443 



50 



55 



60 



} 



The "DYNAMIC section for the example above speci- 
fies that the item box in a Folder starts displaying items in 65 
Report display, does not show a column for creation date, 
does show the time along with the date in the Modified 



column, and has modified column widths. The following is 
an exemplary list of various control properties that may be 
used in embodiments of the invention. 
Control Properties 

controlname: the section to which the control applies, 
child type: which categories of templates may be created 
of this page. 

defaulttarget: set if the template has an item box into 
which items dropped on the icon for this page should go. 

excludechildcount: set on item boxes or discussion whose 
children or notes should not count as part of the page's size, 
like the Attachments box on a Note page, and the embedded 
discussion areas on folders and version organizers. 

substorage; set if creating one of these should also create 
its first child. Used for discussion, so that the page wizard for 
creating a discussion also prompts the user to title and enter 
the first note. 

InitialView: specifies the initial display mode of items on 
this page (Report, Small icon, Large icon). This property 
must be placed within the braces of a DYNAMIC {} 
subsection within the control template. 

Switch Views: allows the page to hide from a user the 
ability to switch modes. This property must be placed within 
the braces of a DYNAMIC {} subsection within the control 
template. 

Create Label: overrides "Create" as the creation button 
label. This property must be placed within the braces of a 
DYNAMIC {} subsection within the control template. 

Title Width: specifies the title column width. Otherwise, 
the title column will size itself dynamically to fill the space 
left by the other columns. This property must be placed 
within the braces of a DYNAMIC {} subsection within the 
control template. 

CreateWidth, ModifyWidth, OwnerWidth, SizeWidth: 
used to specify alternate column widths. This property must 
be placed within the braces of a DYNAMIC {} subsection 
within the control template. 

TitleName, CreateName, ModifyName, OwnerName, 
SizeName: used to override "Name", "Created", 
"Modified", "Owner" and "Size" as the column names. This 
property must be placed within the braces of a DYNAMIC 
{} subsection within the control template. 

ShowSize, ShowOwner, ShowModification, ShowCre- 
ation: allowing display or concealment of these columns. 
This property must be placed within the braces of a 
DYNAMIC {} subsection within the control template. 

ShowCreateTime, ShowModifyTime: set to show time, 
along with date, in these columns. This property must be 
placed within the braces of a DYNAMIC {} subsection 
within the control template. 

ShowSizeSuffix: allows the size column just show a raw 
number, not "x notes", "x items", etc. This property must be 
placed within the braces of a DYNAMIC {} subsection 
within the control template. 

SortColumn: set this to "Create", "Modify", "Owner", or 
"Size" to specify a column other than the name as the initial 
sort key. 

SortAsccnding: specifies reverse or normal sort. 
ShowHeader: set this to "False" to hide the column 
headers. 

Width: set this to the width of the item box. This property 
is used to make sure the icons for newly created items are 
given the correct XY coordinates for Large Icon mode. 

AnnotationTarget: set this to the name of an item box in 
the current template to make the Edit New Version command 
appear for items in this item box. The new copies will be 
sent to the item box specified. 
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The Wizard section: this section defines the functions 
used for creating and editing the page. Each widget in 
the wizard is listed here, with properties controlling 
what sort of widget it is (checkbox, plain text or rich 
text), the text of the prompt that appears before it, and 
the default value. The Wizard section in a Folder looks 
like this: 



Begin_Wizard 
{ 

Name 



{ 

widgettype « text 

prompt = "Name" 

default 

indent - 32 

DYNAMIC 

{ 

longdescription - "Choose a name for this folder, and 
add a description of you want one.*' 

} 

} 

Use Description 



{ 



widgettype » checkbox 
prompt = "Show description" 
default = TRUE 



} 

Description 
{ 

widgettype - rich__text 
prompt - " " 
default 
indent - 0 
DYNAMIC 



15 



20 



25 



richtextheight - 153 



} 



} 

UseComments 

{ 

widgettype = checkbox 

prompt = "&Include space for comments" 

default « TRUE 

} 



35 



The widget section described above specifies four editable 
widgets in the wizard: a text box for the title, checkboxes for 
whether or not to use the description and the embedded 
discussion, and a rich-text box for the optional description. 45 
The following is a list of wizard properties that may be used 
in various embodiments of the invention. 

Wizard Properties 

Widgettype: which edit widget to use for the property. 
Can be "text", rich-text" or "checkbox". 50 

Prompt: the text to show before the widget. 

Default: the default value for the property 

Indent: how much to indent the widget to the right of the 
prompt. An indent of 0 means to put the widget below the 
prompt, not the right of it. 55 

Longdescription: This property must be placed within the 
braces of a DYNAMIC {} subsection within the control 
template used on the first widget in the Wizard section, to 
provide an optional extra line of instructions to appear at the 
very top of the wizard page. 60 

Richtextheight: used on rich-text widgets, to control their 
height. This property must be placed within the braces of a 
DYNAMIC {} subsection within the control template. 

The header for many pages also includes an "INCLUDE" 
tag, which refers to additional header information for 65 
embedded discussions (see below), which is stored in a 
separate template for convenience. 



Referring once again to FIG. 5, once the appropriate 
template has been retrieved from mass storage associated 
with the client workstation (step 502), the next step taken by 
the page builder application is to replace all of the Replace 
Properties contained in the template with project informa- 
tion from the project database (step 504). Following is a list 
of exemplary Replace Properties: 

Replace Properties 

Name, Description, UseDescription, UseComments: edit- 
able properties from the page wizard. 

SROOM: the name of the eRoom. 

SCREATOR: the creator of the eRoom. 

SCREATEDATE: the date and time the eRoom was 
created. Allowable formats are "short," which displays some 
abbreviated form of the date such as date -slash format or 
month-year format, and "long," which displays the full year 
including month year and day. 

SERDATADIR: the full path subdirectory in which 
eRoom data for the page is stored. 

SDISCUSSIONBODY: the body of a discussion. 

SDISCUSSIONINDEX: the list of note titles used for the 
sidebar index in discussions. 

In order to fully render an eRoom the page builder 
application uses the portion of the project database which is 
stored locally on the client workstation 12', as well as any 
files which are stored locally, to "fill in" any replace prop- 
erties contained in the template. For example, if the page 
builder application encounters a SDISCUSSIONBODY 
replace property, it accesses the local database 20 cells that 
contains the discussion indicated by the replace tag and 
includes the text of that discussion in the rendered eRoom 
page. The page builder application may be written as a 
procedural routine that examines an eRoom template for a 
particular set of replace properties; in this embodiment, the 
page builder application would need to be rewritten when- 
ever a new replace property is defined. 

Because multiple users may concurrently, and even 
simultaneously, perform work on a project, the page builder 
must ensure that the objects from the local database and 
locally stored files are not stale before inserting them into the 
eRoom template (step 506). Put another way, the client 
workstation's local project database 20' must be synchro- 
nized with the server's project database 20 to ensure data 
coherency. Synchronization may be done in at least four 
different ways: (1) periodically in the foreground; (2) event- 
triggered in the foreground; (3) periodically in the back- 
ground; and (4) event-triggered in the background. If syn- 
chronization is done in the foreground, then the user is 
blocked from performing any work while the synchroniza- 
tion occurs. Background synchronization allows the user to 
continue working. For example, the object ID for an object 
is used to query the local database 20'. The object record 
may include a modification tag value (as described above), 
or each data object may be provided with one or more state 
bits which can be set to indicate the file or data is stale. If 
the modification tag value or state bits indicate that the 
object needs to be synchronized, the updated object may be 
requested from the server in the foreground or in the 
background. Alternatively, a client workstation 12' may 
periodically search its entire local database 20* for objects 
which need to be updated. This may take the form of a 
database query for objects having a modification tag value 
less than the current value, or a database query for objects 
having a particular value for state bit fields. Objects returned 
by the query are requested from the server as discussed 
above. 

Synchronization is enabled by storing all records in the 
server database with an associated modification tag. The tag 



04/27/2004, EAST Version: 1.4.1 



US 6,230,185 Bl 



11 



12 



is a positive integer which is taken from an ever-increasing 
counter. The counter increments each time it is read, i.e., 
each time a new modification tag is assigned to a data object 
stored on the server 14. When a client workstation 12' 
synchronizes its local databases and files, it also receives the 5 
current modification tag, i.e., it also receives the current 
value of the counter. Alternatively, the current modification 
tag value can be included as extra information in each 
"wrapper page." The client workstation 12' includes the last 
modification tag value it received when it makes a subse- 10 
quent synchronization request. The server 14 transmits to the 
client workstation 12' any data objects to which the user has 
appropriate access rights that also have a modification tag 
value greater than the modification tag value sent with the 
synchronization request. The client workstation 12 stores the 15 
received data objects in its local database and stores the new 
received modification tag value. Client workstations 12' and 
servers 14 may be separated by relatively slow, lossy chan- 
nels such as telephone networks. Accordingly, synchroniza- 
tion requests can sometimes fail for various reasons, e.g., a 20 
connection node is out of service or a necessary transmission 
line suffers too many errors to allow a reliable connection to 
be made. In this event, the synchronization request fails and 
should be retried later. 

Once synchronization has been accomplished and local 25 
database metadata has been updated, the appropriate data 
objects and values are inserted into the eRoom where 
indicated by Replace Properties, and the eRoom is displayed 
to the user (step 508) by the browser application in a 
traditional manner (refer to FIG. 4). 30 

Files displayed by an eRoom may be viewed or edited by 
team members having the appropriate access controls 
(discussed in more detail below). A user indicates that a 
particular file should be retrieved from the server for editing 
or viewing by any one of a number of traditional methods, 35 
such as double-clicking, selecting the file and pressing the 
"Enter" key on the keyboard, or pressing the right-hand key 
on a mouse input device and selecting the appropriate action 
from the displayed pop-up menu. File download and sub- 
sequent upload, if necessary, is managed by a background 40 
daemon. Alternatively, file upload and download may be 
managed by a separately executing program; the only 
requirement is that the file upload/download application 
executes separately from the browser application, so that 
premature exiting of the browser program is handled appro- 45 
priately by upload/download code. 

Referring now to FIG. 6, the first step taken by the 
background daemon is that the local file directory is checked 
to determine if the selected file is already resident in local 
mass storage associated with the client workstation 12' (step 50 
602). If the file is not present or is stale, then it must be 
downloaded from the server 14. The file is checked to 
determine whether another client workstation 12 has caused 
an edit lock to be set on the file indicating that the file is 
being edited. This may take the form of a database query for 55 
the object ID associated with the file which returns at least 
the metadata associated with the file indicating presence or 
absence of an edit lock. If no edit lock has been set for a 
requested file, the access rights of the requesting user are 
checked. If the user has appropriate access rights, i.e., "can 60 
edit" if the user has indicated editing will occur or "can 
view" if the user has indicated only viewing will occur, the 
user will be allowed to retrieve the file. In the case of a user 
that indicated editing will occur, an edit lock is set before the 
file is downloaded. This ensures that no other user will be 65 
able to download the file for editing purposes while the edit 
lock is set. The requesting user is blocked from further work 



until the file download is complete. File transfers are accom- 
plished using HTML and this process is described in more 
detail below. 

Once the file has been downloaded, or if the file was 
already present in local mass storage, the Watcher launches 
the application used to edit the file (step 604). The indicated 
application may be determined using the Object Linking and 
Embedding standard (OLE), the file sufBx (three characters 
in a DOS-based system), or the server 14 may store file 
metadata which is transmitted together with the file and 
indicates which application should be used to open and edit 
the file. If the server 14 stores file metadata, a list of alternate 
applications may be stored, either on the server 14 or the 
client workstation 12, so that if a client workstation does not 
have access to a first application, other applications are 
specified which may be used. 

The background daemon waits for the indicated applica- 
tion to exit, or the document to close, before taking further 
action (step 606). Once the application has exited, the 
background daemon determines if the file has been modified 
(step 508). If not, the background daemon does not need to 
take further action, except for freeing the edit lock if one was 
set. However, if the file was modified, then it must be 
uploaded to the server 14 using HTTP (step 610). The file 
upload may be done in the background or in the foreground. 
If done in the foreground the user will be blocked from 
further work on that file until the upload is complete. Once 
the upload is complete, the server 14 updates metadata 
stored in its database 20 that is associated with the file, for 
example, any edit lock set by the editing user is released. 

As noted above, users may perform work on files and 
objects locally and upload the modified files and objects to 
the server 14 for viewing, comment, or further modification 
by other project team members. The systems and method of 
the present invention allow users to upload newly created 
and modified files to a server 14 using an intuitive drag- 
and-drop method. 

Referring now to FIG. 7, a user creates a new file or 
modifies a file downloaded from the server 14 (step 702). It 
should be understood that this step includes actions such as 
creating a new version of file locally so that other users may 
still check out the "original" copy of the file present on the 
server 14. Once the user is finished editing the file, it may be 
uploaded to the server 14 to allow other users access to it. 
The user signals that the file should be transmitted to the 
server 14 by dragging the file onto an eRoom displayed by 
the browser (step 704). Dropping the file into the displayed 
eRoom invokes an ActiveX control or a background daemon 
process which manages the upload of the file to the server 
14. 

The user's access rights are checked to ensure that the 
user possesses "create" or "modification" rights for the page 
to which the user desires to upload the file (step 706) and the 
file to be uploaded is stored to local mass storage (step 708). 
Access rights may be checked over the network in many 
ways. For example, each object may be provided with a field 
or fields which identify users that may open, view, and edit 
the object. Alternatively, an object may assign a pre-defined 
value to a field which controls access to the object. For 
example, a "coordinator" role may be defined and an object 
may identify that any coordinator may edit, open or view it. 

If the user has the appropriate rights, then a command is 
sent to the server to create a new file (step 710). This step 
may be skipped if the user is modifying a file instead of 
creating a new file. However, creation of a new file allows 
the server to provide a degree of fault tolerance and version 
control, if those features are desired. If the server has been 
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instructed to create a new file, a new object is created 
containing metadata associated with the data file and the file 
is transmitted to the server 14 using HTTP (step 712). If a 
file modification is occurring, the server 14 updates the 
metadata contained by the data object associated with the 5 
file and the file is transmitted to the server 14 using HTTP 
(step 712). The server 14 associates the uploaded file with 
the newly-created data object. 

File metadata may include: the name of the file; the size 
of the file; the date the file was created; the date the file was 10 
last modified; access information such as which users may 
open, view, and edit the file; and information regarding the 
edit status of the file, such as whether an edit lock has been 
set by a user. 

HTTP Transfer Protocol is 
Throughout the specification, whenever reference is made 
to transmitting data to or from a client workstation 12', the 
transfer is accomplished using HTTP. While this is the 
traditional way to transmit HTML files from severs to 
clients, it is not used to transmit HTML files from clients to 20 
servers. The systems and methods described herein use 
HTTP to transmit large files of data, such as word processing 
files, spreadsheets, etc. The advantage of using HTTP to 
transmit all project data is that users from different organi- 
zations can easily and transparently share data since data 25 
transmitted by HTTP will be more compatible with firewalls 
or other security mechanisms established by their respective 
organizations. 

Referring now to FIG. 8, the first step in transmitting data 
using HTTP is that the client workstation 12' obtains any 30 
proxy server settings in use by the browser application 
executing on the client and stores those proxy settings for 
later use (step 802). The client workstation establishes an 
authentication context by connecting to a server using a 
series of HTTP commands (step 804). This is much like the 35 
process used for logging into a server 14 hosting eRooms, 
and is described in greater detail below. An authentication 
context may be any method for establishing the identity of 
a remote user; a common context is a username-password 
pair. 40 

The client workstation 12' establishes an HTTP connec- 
tion to the server 14 (step 806) using the proxy settings 
stored in step 802 and sends an HTTP POST request to the 
server 14. The HTTP POST request includes: a URL iden- 
tifying a directory located on the server 14 where the data 45 
should be stored; an identification code uniquely identifying 
the data; a header containing information about the data such 
as authorization information; and the data itself. 

Once the eRoom server 14 has verified the uploading 
user's authentication context, e.g., username and password 50 
pair, it receives the data and stores it based on the document 
identification code transmitted in the HTTP POST command 
(step 808). 

Access Control 

As noted above, the eRoom skeleton is the set of database 55 
records that contain the basic properties needed to display an 
eRoom. The concept of skeleton information provides a first 
level of access control, because only data objects stored in 
"containers" for which a particular user has Open privileges 
are synchronized to that client's workstation 12'. 60 

Since every file and eRoom item is represented as an 
object in the database, access of users to each item can be 
controlled by entries in the database schema. For example, 
every eRoom may be represented by a table which has one 
or more of its fields a list of the members that are entitled to 65 
enter the eRoom. In some embodiments, users may be 
divided into three separate groups: coordinator; reader; and 



participant. In this embodiment, a coordinator can add 
members to the eRoom and may supersede any rights 
granted to users. A reader is someone who has access to the 
eRoom solely to view the content of that eRoom while a 
participant is a user that may access the eRoom and may edit 
the objects and files contained in the eRoom as well as 
upload new objects and files to the eRoom. User access may 
be checked by running the database query on the appropriate 
table and only allow a user to access the eRoom when that 
user's name or authentication context appear as an entry in 
the table, i.e., is returned from the database query as a result. 

Some embodiments, include a "persist layer" which pro- 
vides persistent storage to a relational database. The persist 
layer provides an application program interface which 
allows application programs to issue individual commands 
to relational databases, each command providing a flexible 
number of input parameters and output return values. Each 
persist command may be mapped to a database query 
statement that is used when the command is executed. This 
mapping is encapsulated, i.e., hidden from clients of the 
persist layer. Encapsulation of the persist commands allows 
them to be redirected to different databases or optimized 
without requiring the client application program to be modi- 
fied. 

In another embodiment, the persist layer described above 
is based on the ODBC protocol. ODBC allows an applica- 
tion program to "prepare" a data query and then execute the 
prepare statement multiple times. Execution of prepared 
statements offers significant performance improvements. 
The "persist layer" may further monitor which statements 
are executed most often. Based on statement execution 
counts, statements may be dynamically prepared based on 
their usage. In some embodiments, a statement may be 
prepared for a limited period of time, after which it is 
"unprepared." Alteratively, a statement may be prepared 
after a certain number of uses and then be unprepared if it 
is not used within a certain period of time. 

Discussion and Vote/Poll Items 

As noted above, discussion items and vote/poll items may 
be associated with other items contained in an eRoom or 
those items may be independent of other items. FIG. 9 
depicts an embodiment of an eRoom that contains an 
independent discussion item 902 in the item box 408. When 
provided as an independent item in an eRoom, discussion 
items 902 and vote/poll items behave as any other item. That 
is, they may be moved, renamed, or opened by double 
clicking. FIG. 10 shows an example of a discussion item that 
has been opened by double clicking. Alternatively, a discus- 
sion item may be associated with a particular item or 
otherwise embedded within an eRoom or item contained in 
an eRoom. FIG. 11 depicts an embodiment of an invention 
in which a discussion item 1102 is associated with a note 
item 1104. In this embodiment, the discussion item 1102 
allows users to provide comments they may have regarding 
the note item 1104. 

As noted above, when a discussion item is associated with 
an eRoom page, a SDISCUSSIONBODY replace property is 
embedded in the HTML code representing the eRoom which 
contains the discussion. When a page builder application 
encounters a SDISCUSSIONBODY replace property, the 
application accesses the local database 20 cells that contain 
the discussion indicated by the replace tag and includes the 
text of that discussion in the rendered eRoom page. Thus, in 
the embodiment shown in FIG. 11, the eRoom would have 
a replace property embedded in the HTML code represent- 
ing the eRoom for the discussion group associated with the 
note. 
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As shown in FIG. 10, individual entries in discussion a free text entry field 1220 into which the creator of the 

group items may include an indication of the subject of the vote/poll item can enter an alphanumeric string representing 

entry 1108, an indication of the author of the contribution the question to be put to the participants. The create dialog 

1110, the date and time of the contribution 1112, and the box 1200 may also include a free text entry field for 

contribution to the discussion itself 1114. In the embodiment 5 allowable votes that may be cast by a discussion group 

shown in FIG. 10, each contribution to the discussion group member. In this embodiment, the creator of a vote/poll item 

also includes a modify icon 1120 for creating a discussion nas entered three choices that discussion group members can 

group entry that may have been precipitated by the entry, a choose: y es; D0 ^ and tr ? later - ^ crcale dialo S box 1200 

delete icon 1122 which allows authorized users to delete the also L allows y ^ rs t0 P r0Vl T de alternate means of responding 

entry, and an immediate reply icon 1124 which allows a 10 * vo{c ^f <i ucstl0D - ^ the , embodiment shown in FIG^ 

reply to the discussion item to be created. Immediate replies }}> tW ° f ar f V™ ld& * * al * n ™ %%* i0T f 

, ,. A . , j - jl ii_ * • the vote/poll question to allow write-in votes 1222 or to 

are in one embodiment, associated with the entry proxi- aUow a discus ^ on member to cast muW le votes for 

mally. In one particular embodiment, immediate replies are lhe same tkm U24 [n the embodiment shown in plG. 

indented and appear directly beneath the entnes to which n the CTeatc dialog box nm alsQ provkJes a chcck box 

they respond. Access to a discussion group entry to delete or 15 allowing the creator to have the responses to the vote/poll 

modify it is controlled as described above. question be public or private 1226. The creator creates a 

FIG. 10 shows a stand-alone discussion group. A stand- vote/poll item by clicking the finish button 1250 after 

alone discussion group has a richer set of features than a entering information in the create dialog box 1200. If the 

discussion group associated with an item. For example, a creator elects not to create a vote/poll item, then the user 

stand-alone discussion group includes one or more topics of 20 may click the cancel button 1252. 

discussion 1180. Each individual topic represents a "thread" Referring back to FIG. 10, a vote/poll item 1150 is 

of discussion in a discussion group. In the embodiment depicted as it might appear embedded in a discussion group, 

shown in FIG. 10, a thread called "Templates" is currently As depicted in FIG. 10, the vote/poll question entered in the 

displayed. Another thread can be viewed by clicking on the free text dialog box 1220 appears as a question to the user 

desired hypertext topic. Users may also add new topics. In 25 1152. The vote/poll item 1150 presents the results of the 

the embodiment shown in FIG. 10, a "start a new topic" survey at the time the user accesses the discussion group, 

button 1182 is provided. A user begins a new topic by Because of the dynamic nature of HTML pages, the polling 

clicking on the button 1182. mechanism updates the results of the question at the location 

Stand-alone discussions may have attachments associated it is embedded in the discussion group item. The results of 

with them. In the embodiment shown in FIG. 11, the note 30 the vote/poll may be updated when the client local database 

item 1104 has an attachments area 1116 associated with it. is synchronized, as described above, or the results of the 

Data, files, and other items can be dragged and dropped into vote/poll may be updated by the user clicking the refresh 

the attachments area 1116. Thus, for example, a stand-alone control 1190 provided by the browser. The vote/poll item 

discussion group may have an attachments area 1116 asso- also provides a mechanism for each viewer in the discussion 

ciated with it to allow discussion group participants to post 35 group to vote. In the embodiment shown in FIG. 10, a vote 

material collateral, or supportive, of the discussion. button 1160 is provided. The vote/poll item depicted in FIG. 

FIG. 11 shows an embodiment of a discussion group 10 also shows the votes cast in response to the survey 1162. 

associated with a note item. A discussion group that is not a This feature is enabled when the check box for showing each 

stand-alone item will be referred to as an "embedded dis- person's vote 1226 is checked in the create dialog box 1200. 

cussion." In the embodiment depicted in FIG. 11, embedded 40 The vote/poll item also provides a mechanism for the creator 

discussions have no provisions for "threads," that is, there is to delete the vote/poll item once a decision has been reached, 

only one topic for discussion. Also, users are not given the In the embodiment shown in FIG. 10, a delete control 1170 

ability to create immediate replies to previous discussion is provided associated with the vote/poll item, 

items in this embodiment. In other embodiments, users may In other embodiments, the vote/poll item may provide 

be given the ability to make immediate replies and create 45 other controls which can be configured by the creator of the 

"thread" topics in embedded discussions. vote poll item, such as requiring each user to vote, allowing 

In the course of conducting a discussion on a particular certain users to have the option to vote but not requiring 
topic of interest, whether embedded or stand-alone, a con- them to vote, notifying certain users to vote, specifying a list 
tributor to the discussion may survey the discussion group of users that are required to vole for a result to be valid or 
members with regard to a particular question. To do this, the 50 reminding users to vote after a pre-determined amount of 
contributor creates a vote/poll item using the create control time has passed without a vote being cast by that user. The 
446 (shown in FIG. 4). FIG. 12 depicts one embodiment of vote/poll object controls the number of votes that may be 
a dialog box displayed to a user that has selected the create cast by any member and, in certain embodiments, limits the 
control 446. The dialog box 1200 includes a number of number of votes a member can cast to one. Such a feature 
controls allowing the user to specify the form the vote/poll 55 may be provided by consulting the database entry represent- 
item will take, as well as the content of the vote/poll item. ing the vote/poll item before accepting a vote from a user. In 
For example, in the embodiment depicted in FIG. 12, the particular, if a user submits a response to a vote/poll item, 
user is able to select the font in which at least some portion the server compares the identity of the user submitting the 
of a vote/poll question will be presented to discussion response to the database item representing the vote/poll item 
participants using the font pull down menu 1202. Similarly, 60 to determine if the user's identity already exists in a list of 
the user is able to select the size of at least some portion of users that have responded. If the user's name appears as 
the question using the font size pull down menu 1204. having previously submitted a response, then that user's 
Controls may also be provided for allowing at least some submission may be discarded. In a particular embodiment, 
portion of the question to be presented to users in bold text once a user has cast a vote, the "vote" button 1160 does not 
1206, italicized text 1208, underlined text 1210, left justified 65 appear or appears "grayed out," Access to a vote/poll item 
text 1212, centered text 1214, and right justified text 1216. in order to edit or delete that item is controlled as described 
In this embodiment, the create dialog box 1200 also includes above. 
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Licensing and Distribution 

A method and apparatus for distributing the product to 
users that ensures only licensed users are able to use the 
product will now be now described. Although the method 
and apparatus will be described in relation to the systems 
described above, it should be understood that the distribu- 
tion methods and systems described may be used generally 
for any product. Referring now to FIG. 13, the steps to be 
taken to electronically distribute and control access to a 
product are shown. A request for the product to be distrib- 
uted is received (step 1302). The product request may be 
received via network means, by mail, by telephone, or in 
person. For embodiments in which product requests are 
received via network means, the product requests may be 
received by a server node. The server node receiving the 
request, in one embodiment, both stores the product and 
receives the request. In other embodiments, the server may 
also respond to the received requests. In still other 
embodiments, the server receiving the requests may not 
store the product but instead may communicate with other 
servers which store the product and respond to the request 
when notified by the server node receiving the product 
request. 

After a product request is received, a license string is 
generated (step 1304). The license string is generated sub- 
stantially at the time the request is received. The string may 
be generated upon receipt of the request but not transmitted 
to the requestor until payment is verified, or the string may 
be generated after payment is verified. The license string 
may be derived from information associated with the 
product, information associated with the request, or other 
information that allows the license string to be verified when 
entered into the product by a user to gain access to the 
product. In some embodiments, the license string may be 
generated from the version of the product that is to be 
delivered. In other embodiments, the license string may be 
generated based on the creation date of the product, or the 
date of the product request. In the foregoing description, 
reference made to date should be understood to include both 
date as well as date and time together. In one embodiment, 
the license string is generated using a checksum which may 
be validated by the product before allowing a user access. In 
other embodiments, the license string is generated using 
block ciphers. In still other embodiments the license string 
is generated using a symmetric stream cipher such as RC2, 
RC3, RC4, or RC5. In one particularly preferred 
embodiment, the license string is generated using the MD5 
message digest algorithm, which takes a message of arbi- 
trary length as input and produces a 128-bit output. 

In one particular embodiment, the license string is gen- 
erated in the following manner. A data structure is generated 
containing the current time, the type of license to be 
generated, the number of users to be authorized by the 
license, and a randomly generated number. Validation data is 
generated based on the created data structure and a secret 
key using the MD5 encryption algorithm. The binary data 
representing the data structure and the validation data is 
encoded into a 24 character human readable string com- 
prised of uppercase English characters (excluding capital 
"O" and capital "I") and the digits 2 through 9 inclusive. 
Encoding the binary data into the human readable string may 
be done in any reversible fashion. For example, the binary 
data can be viewed as a series of 8-bit ASCII character 
codes, resulting in an alphanumeric string generated by the 
binary data. 
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Once generated, the license string is transmitted to the 
requestor. As noted above, the license string may be trans- 
mitted via network means, by mail, by telephone, or in 
person. The product receives the license string input by the 

5 requestor (step 1308). The requestor may input the license 
string by typing the license string into an entry field provided 
by the product. 

The product verifies the license string input by the 
requester (step 1310) by, in some embodiments, verifying 

10 that the check sum is accurate. In other embodiments, the 
license string is verified by decrypting the encrypted string. 
Once the license string has been decrypted, the alphanu- 
meric input string may be analyzed to determine if it is a 
valid string (step 1312). In some embodiments, this is 

is accomplished by determining whether certain elements of 
the string fall within logical parameters, such as string 
generation date. For example, in this embodiment, if a string 
indicates that it was generated in a year before computers 
were invented, the string is likely invalid. In other 

20 embodiments, a checksum may be used in addition to an 
encryption technique. In these embodiments the string's 
validity is determined by ensuring that a valid check sum is 
produced. If the product determines that the string is invalid, 
then access is denied to the requestor (step 1314). 

25 Alternatively, if the license string is valid then the requester 
is allowed access to the product (step 1316). 

In one particular embodiment, the license string entered 
by a user is validated in the following manner. The human 
readable string entered by the user into the product is 

30 translated into its binary representation which consists of 
two parts: the license data and the validation data. As noted 
above, the binary data encoding is reversible and, therefore, 
the human readable character string can be used to recover 
the binary data string generated as described above. Using 

35 the example described above, if binary data is converted into 
a human readable string using ASCII character codes, then 
recovery of the binary data requires only that the conversion 
from character code to binary data be performed. The binary 
license data recovered from the human readable string is 

40 used to generate a new set of binary validation data for the 
license. The generated validation data is compared to the 
validation data encoded in the license string. If the generated 
validation data exactly matches the encoded validation data 
then the license is accepted as valid, that is, the license string 

45 has not be altered or otherwise subjected to tampering. 
A license string may allow one or more users access to the 
product. For the systems described previously, license 
strings are entered into the product via a dialog box, and a 
license string allows users of a particular facility access to 

50 the product. Such a license will be referred to as a facility 
license. In one embodiment, the identity of particular autho- 
rized users is associated with a license string when it is 
entered, and only those particular users are granted access to 
the product. In other embodiments, the license string enables 

55 a predetermined number of users to access the product and 
any users are allowed access to the product provided that the 
total number of users does not exceed the predetermined 
number of authorized users. 

In another implementation, an organization may provide 

60 multiple facilities for use by its members. In this 
embodiment, it is desirable to provide a license to the 
organization that allows members of the organization to use 
any facility. Such a license will be referred to as an enter- 
prise license. An enterprise license is stored in a central 

65 repository that can be accessed by all facilities. In one 
embodiment, the enterprise license is stored on a separate 
server and all facilities access the licenses on that server. In 
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other embodiments, a server that hosts a facility may also 
store the enterprise license. For embodiments in which 
particular users are identified by the enterprise license, each 
such user will appear in the authorized user list for each 
facility. 5 

As an illustrative example, consider an enterprise having 
two facilities: Facility A and Facility B. If users I, J, and K 
are specifically authorized by the enterprise server, then 
users I, J, and K may access either Facility A or Facility B. 
Put another way, users I, J, and K appear on a list of 
authorized users stored by a main server, and Facility A and 
B access the main server to construct their local list of 
authorized users. 

When, for example, user K attempts to access Facility B, 
Facility B first checks any local facility licenses to determine 
if K is an authorized user. If no facility licenses exist, or if 15 
K is not authorized by an existing facility license or licenses, 
Facility B checks for an enterprise license. If no enterprise 
license exists, or if an existing enterprise license or licenses 
does not authorize user K, then access to Facility B is denied 
user K. 20 

Access to a facility may be controlled by one or more 
enterprise licenses, one or more facility licenses, or any 
combination of facility licenses and enterprise licenses. 
Each license has its own license string that must be entered 
into the product to allow access. In the example described 2 s 
above, a single enterprise license can authorize both a core 
set of users for all facilities as well as a number of local users 
for each facility. An enterprise server may, as described 
above, maintain a list of authorized users containing I, J, K. 
An enterprise license allowing five users access to the 3Q 
product allow I, J, and K to access any facility in the 
enterprise that is associated with the enterprise server main- 
taining the list of authorized users. A fourth user, user M, 
may desire to be added to the local authorized user list for 
one of the facilities. Before the facility adds user M to it's 
local list of authorized users, it determines if the number of 35 
users in its authorized user list after adding M exceeds the 
number of users authorized by any local facility license plus 
any enterprise license. If not, then user M is added. 

In some embodiments, the product may be fully func- 
tional when distributed. In these embodiments, the product 40 
may be configured to disable itself within a predetermined 
period of time unless a valid license string is entered. Data 
entered by users while the product was in its "trial" period 
may be made read-only, in order to preserve user work 
product. In certain of these embodiments, license strings 45 
may be generated that extend the "trial" period by a prede- 
termined amount of time. 

While the invention has been particularly shown and 
described with reference to specific preferred embodiments, 
it should be understood by those skilled in the art that 5Q 
various changes in form and detail may be made without 
departing from the spirit and scope of the invention as 
defined by the appended claims. 

What is claimed is: 

1. A method for facilitating communication between ss 
collaborators in a network environment, the method com- 
prising the steps of: 

storing project data associated with an HTML page to be 
displayed to a collaborator and including an indication 
that the HTML page includes at least one discussion 60 
among collaborators; 

storing a template file associated with the HTML page 

processing the stored project data in conjunction with the 
stored template file to generate the HTML page for 
display wherein the HTML page includes a discussion 65 
among collaborators; and 

displaying the HTML page to the collaborators. 



2. The method of claim 1 further comprising, 
storing discussion group data with the project data; and 
processing the discussion group data with the project data 

and the template file to generate the HTML page for 
display. 

3. The method of claim 1 further comprising, enabling the 
collaborators to add to the discussion included in the HTML 
page. 

4. The method of claim 1 further comprising embedding 
the discussions within the HTML page. 

5. The method of claim 1 further comprising including an 
item in the HTML page and enabling the collaborators to 
associate the discussion with the item included on the 
HTML page. 

6. The method of claim 1, wherein the discussion includes 
a plurality of topics, and the method further comprises, 
displaying a delineation between each of the plurality of 
topics. 

7. The method of claim 1 further comprising, 
providing an indication of a plurality of items on the 

HTML page; 

displaying an embedded discussion among the collabo- 
rators on the HTML page; and 

visually associating the embedded discussion with one of 
the plurality of indicated items on the HTML page. 

8. The method of claim 1 further comprising, including a 
vote/poll item on the HTML page. 

9. The method of claim 1 wherein the data stored in the 
database includes an indication that the HTML page 
includes at least one vote/poll item embedded within the 
discussion. 

10. The method of claim 9, wherein the discussion 
includes discussion entries and the method further 
comprises, embedding the vote/poll item between the dis- 
cussion entries. 

11. The method of claim 8 further comprising, enabling 
the collaborators to cast a single vote via the vote/pole item. 

12. The method of claim 8 further comprising, enabling 
the collaborators to cast multiple votes via the vote/pole 
item. 

13. The method of claim 8 further comprising, enabling 
the collaborators to cast write-in voles via the vote/pole 
item. 

14. The method of claim 8 further comprising, requiring 
the collaborators to cast a vote in response to the vote/poll 
item being included in the HTML page. 

15. The method of claim 8 further comprising, prompting 
the collaborators to respond to the vote/poll item. 

16. The method of claim 8 further comprising, enabling 
the collaborators to respond to the vote/pole item, wherein 
responses to the vote/poll item are not displayed. 

17. The method of claim 1 further comprising, enabling 
the collaborators to cast votes associated with the discus- 
sion. 

18. The method of claim 17 further comprising, display- 
ing the votes cast by each of the collaborators to all of the 
collaborators. 

19. Hie method of claim 1 wherein the discussion com- 
prises a plurality of entries and the method further 
comprises, visually indicating on the HTML page to which 
of the collaborators each of the entries is attributable. 

20. The method of claim 19 further comprising, 
enabling the collaborators to provide a response to a 

particular one of the plurality of entries; and 
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visually indicating on the HTML page that the response is 
provided to the particular one of the plurality of entries. 

21. A method for facilitating communication between 
collaborators in a network environment, the method 
comprising, 

storing project data associated with a page to be displayed 
to a collaborator and including an indication that the 
page includes at least one discussion among 
collaborators, 
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storing a template file associated with the page, 

processing the stored project data in conjunction with the 
stored template file to generate the page for display, 
wherein the page includes a discussion among 
collaborators, and 

displaying the page to the collaborators. 
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